\section{Design} 
\label{sec:design}

\begin{figure} 
\includegraphics[scale=0.8]{figs/design}
\caption{The big picture of the secure protocol.}
\label{fig:design}
\end{figure}



In this section we propose the design of securing the communication of our
system. In Figure~\ref{fig:design} we can see the proposed architecture of our system.

Users interact with a web server that produces dynamic content using through
status data pulled from many nodes. Moreover users can send commands to the
nodes and read the resulting state. Nodes of the p2p network can connect
between them to exchange data. Initiator of such a process is the web server,
who provides each node with the IP address of the other. The connection between
two nodes is terminated after a command is served. Users have to authenticate
on the web server and can see only the state of the nodes that are online and
they own. Finally, all nodes of the p2p network are always connected to the web
server and keep an open connection in the case of emergency.



\subsection{Entities}

The entities consist the architecture are: a) \emph{Node:} the vehicle or mobile device,
b) \emph{Web Server:} A simple interface for the control of the fleets, and 
c) \emph{Certificate Authority (CA) Server:} Provide basic futures of PKI, such as 
issuing certificates and Online Certificate Status Protocol (OCSP).


\subsubsection{Node}

The node it sef is s simple application that has access in local file system,
and it can provide information about system's resources.  Node has four
categories of messages:

\begin{itemize} 

\item \emph{Protocol related:}: This category includes messages for
authendication, online certificate status protocol and emergency messages.

\item \emph{Status:} The messages related for the system status.

\item \emph{Data:} Messages related for file transfer.

\item \emph{Commands:} Specific commands pushed from the web interface.

\end{itemize}

\subsubsection{Web Server}


Users can send commands to the p2p network nodes via the web service,
then pushes them to the appropriate nodes, and read the resulting state.


For the values passing of the web forms we use the POST request to avoid passing in cleartext
sensitive information. A POST request sends additional data to the web server, specified after the
URL, the headers, and a blank line to indicate the end of the headers. In contrast GET request passes
all the arguments through the links.


\subsubsection{Certificate Authority Server}

The CA issues digital certificates that contain a public key and the identity
of the owner.  The certificate is also an attestation by the CA that the public
key contained in the certificate belongs to the person, organization, server or
other entity noted in the certificate.



Various methods of mitigating this risk have been devised, known broadly as
certificate revocation schemes\cite{tradeoffs-crl}. In this paper, we use
the Online Certificate Status Protocol (OCSP) that is the best solution for our
application.  Nodes are always connected, loss of connectivity means that node
is unavailable for any command. This means that a local certificate revocation
list has no use when a node is offline. Moreover the design using an online
protocol instead an offline with periodic updates simplifies the overall design.





\subsection{Adding Nodes}


\begin{figure}
\includegraphics[scale=0.5]{figs/cert_req}
\caption{Protocol of issuing certificates for a node.}
\label{fig:cert-reg}
\end{figure}

A user can add different nodes in the system and control them through the web
interface. However a new node has to get a new calid signed certificate. If a
valid certificate not exists localy then asks from the user some information,
such as the name and email, to complete the registration process. In
Figure~\ref{fig:cert-reg} we can see the protocol we are use for new
certificates. More precisely the steps for a new certificate of the node are:


\begin{enumerate}
\item Node creates public/private key
\item Node connect to web server 
\item Check the certificate (node has CA certificate)
\item Node create an X509 certificate request signed by node's private key
\item Node sends the X509 certificate request 
\item Web server checks the X509 certificate request 
\item Web Server creates a signed X509 Certificate
\item Send back the certificate signed 
\item Node checks certificate and stores it
\end{enumerate}


Finally we must note that all nodes of the network have an secure socket always
connected to the web server, in cease on emegerncy. The initiation of the
emergency connection is done after the node gets the new certificate.



\subsection{Server to Node Operation}




Communication between web server and node is done using SSL sockets.  When the
server pushes commands to a node, first check if the certificate is valid and
then sends the actual command. A user can send commands to nodes and receive
their answer in XML form.

As discussed before a node keeps an open connection to the server all the time.
When the connection lost, the server deletes the node from the active list,
however we do not revoke the certificate because the loss of connectivity may
be temporary.

When a node connects to the server, it always provides its certificate. If the
common name of client's certificate is different than the actual IP address
then the server denies the connection. 



\subsection{Node to Node Communication}

\begin{figure}
\includegraphics[scale=0.6]{figs/transfer}
\caption{Example of data exchange between nodes.}
\label{fig:transfer}
\end{figure}


In every interaction with other nodes node should check for revocation list

Nodes of the p2p network may connect between them to exchange data. The
initiator of such a process is always the web server, who provides t each node
with the IP address of the other. The connection between two nodes should be
terminated after a command is served.

In every interaction of the node asks the server for validation of the
certificate.

\begin{enumerate}

\item Node A and Node B connect to certificate authoritysent its certificate to node1.

\item User requests transfer file from Node A to Node B.

\item Web server first sends to Node B to listen in a specific port, and then to node B information about Node A (ip and listen port).

\item Connect Node A to Node B. In this step each node will check if certificate is signed by CA or the issue/expire date.

\item Check if certificates are valid with Online Certificate Status Protocol (OCSP). Requests are signed, and include nonce 
to avoid replay attacks.

\item If certificate is valid then the connection is established.

\end{enumerate}




\subsection{Security Model}

In this section we analyze the security aspects of our design.  First we asume
that the web and authority server are in secure location, and we can trust
them. Next we will present that the system is secure in many ways.


All transmitions from and to server are secured using SSL TCP sockets. In all
cases the client (node) provides its certificate when connect to the server,
except certificate request. The certificate request is a special type of
message, the node creates a certificate request that its used from authority to
create the actual signed certificate.  In case of node to node communication
the node along with stadard tests (like time ) also checks through OCSP if the
certificated provided is revoked. 

The passive attackers are unable to compromise us due to usage of SSL TCP
sockets.  The architecture protects from the active attackees through signed
certificates and OCSP.  More over using advanced feutures such as the nonce
extention of OCSP and the certificate usage in the client can increase the
security to acceptable level.



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\section{Implementation}
\label{sec:implementation}


We build a prototype based in the system architecture described previously.  The
web interface is based on apache and mod\_python module.  For the nodes we are
using python 2.6 and the system test was Ubuntu linux 8.10.  Furthermore we
used an extra library for openSSL wrapper along with the sqlalchemy for the
database transactions.


CA authority was build using the same building blocks like nodes. More the CA
authority and the OCSP server are under in the same application.  CA store the
issued and revoked certificates in MySQL database and when a OCSP request is
received, a database query is issued search for the certificate.





%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Limitations} 
\label{sec:limitations}


Our architecture design does not protect us from different DoS attacks.  DoS
attacks are very difficult to prevent, especially in a wireless medium. In our
proposed design we don't protect from DoS from side channels such as jamming.

Moreover our proposed architecture does not aim don't aim the privacy
protection. For example if an attacker tries to connect in a node then he can
find information about the node's owner. This mainly causes from the usage of
certificate from the SSL socket.


Finally we have some limitations in our implementation. First the interface of
our application is limited and we do not enforce advanced access control, such
as policy time out or signed cookies. Second due to bug in the m2crypto library
the node does not provide the loaded certificate when connects to a server.
Third our implementation cannot be used behind NAT or firewall due to limited
support of UPNP protocol from python.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


